你終於把隱形工作搬到檯面上，看見團隊的時間都被什麼吃掉。但今天，你發現了一個更大的問題。

那個問題叫 Brent。

場景：最強工程師，也是最大瓶頸

Steve 又來了。「Phoenix 兩週後上線，你有把握嗎？」

你打開部署流程文件。準確地說，是「文件」這個詞的諷刺版本——一份兩年沒更新的 Word 檔，裡面寫著「詳細步驟請洽 Brent」。

你打開上個月的 Slack 記錄，搜尋「@Brent」：

• 47 次有人 @ 他求救
• 「Brent 這個環境變數要怎麼設？」
• 「Brent 為什麼 staging 部署失敗？」
• 「Brent 資料庫權限可以幫開一下嗎？」
• 「Brent 上次你改的那個 script 在哪？」

去找 Brent。他的桌上有三台螢幕，終端機視窗疊了十幾個，Slack 訊息跳個不停。

「Brent，Phoenix 部署流程能不能寫個完整的 runbook？」

「可以啊，但現在有點忙。」他切到另一個視窗。「QA 說測試環境又掛了，我得先處理。對了，剛剛財務那邊說 API 回應變慢，我要查一下 log……」

你默默數了一下：他同時在處理六件事。

你問其他人：「如果 Brent 明天請假，Phoenix 還能部署嗎？」

沉默。

「……應該可以吧？」後端 Lead 猶豫地說。「只是可能要試幾次。」

「上次 Brent 休假，我們部署失敗三次，最後還是打電話把他叫回來。」QA 補了一刀。

你突然懂了。

Brent 不是你的超級英雄。他是你的單點故障。

兩難：保護短期進度？還是保護長期系統？

Steve 的話在耳邊回盪：「兩週後上線。」

你知道，如果讓 Brent 繼續救火、繼續當「萬能鑰匙」，Phoenix 也許真的能在兩週內硬上。

但如果 Brent 哪天發燒、生病、被車撞——整個 IT 部門就癱瘓了。

你盯著白板，畫出兩條路：

如果是你，現在作為 Bill Palmer，CEO 在等你的承諾，你敢不敢說「我要把 Brent 從 Phoenix 移除」？

先別往下看

認真想三十秒。

你會選 A 還是 B？

為什麼？

翻牌：英雄主義撐不起系統

正確答案是 B。

但重點不是「趕走英雄」，而是 保護瓶頸。

這是 Eliyahu Goldratt 在《目標》裡提出的 Theory of Constraints（限制理論）：

系統的產出，永遠被最慢的那個環節（瓶頸）決定。

如果你不保護瓶頸，反而讓它一直被打斷、被浪費，整個系統就會崩潰。

Brent 就是你的瓶頸。他是全公司最懂系統的人，也是唯一能處理某些關鍵問題的人。

理論上，他的時間應該發揮最大價值——處理只有他能做的關鍵任務。

但現在， his 時間被什麼吃掉？

• 「幫我開個權限」（10 分鐘，其實權限申請流程應該自動化）
• 「這個 script 怎麼用」（5 分鐘，應該有文件但沒寫）
• 「上次改了什麼為什麼會錯」（20 分鐘，因為沒有變更記錄）
• 「能不能幫忙看一下 log」（15 分鐘，別人不知道 log 在哪）

這些全是可以由別人做的事，如果有文件、如果有 runbook、如果有自動化。

但因為沒有，所以大家只能找 Brent。

Brent 的時間被這些「本該別人做的事」吃光，他根本沒時間處理真正只有他能做的難題。

更糟糕的是：每一次「Brent 救火成功」，都在強化「找 Brent 就對了」這個習慣。

沒人記錄他怎麼做的，沒人學到他的方法，下次遇到同樣問題，大家還是找 Brent。

這不是 Brent 的錯，這是 系統設計的問題。

《鳳凰專案》裡，主角 Bill 後來在 Erik（那個神秘的董事會顧問）的引導下理解到：

Brent 就像工廠生產線上的瓶頸機器。

你不會讓瓶頸機器去做雜事，去處理原本該其他工作站做的工作。你會保護它，緩衝它，讓它專注在它獨有的價值上。

你會在它前面建立緩衝（buffer），確保它不會空轉；你會確保它產出的東西不會因為後面的問題被浪費。

套到 Brent 身上：

1. 把 Brent 從低價值的救火中解放出來
2. 把他的知識變成文件、runbook、自動化
3. 讓別人也能做那些「本來只有 Brent 能做的事」
4. 讓 Brent 專注在真正的難題上
5. 在他的前面建立「緩衝」——讓簡單問題被 Agent / 文件 / 其他人擋掉

Bus Factor = 1 是系統設計問題，不是人的問題。

改變的關鍵是：停止獎勵「Brent 又救了大家」，開始獎勵「這次沒有找 Brent 也解決了」。

如果你有 AI Agent：把 Brent 的大腦複製出來

問題是，Brent 每天忙到爆，哪有時間寫文件？

而且就算寫了，下次遇到同樣問題的時候，大家還是會直接 @ Brent，因為「問人比翻文件快」。

這時候，AI Agent 可以幫你做一件事：Knowledge Agent 坐在 Brent 身邊，把每次操作轉成可複製的 runbook。

graph TB
    A[有人 @ Brent 求救] --> B[Agent 記錄整個過程]
    B --> C[問題/原因/步驟/指令]
    C --> D[自動生成 Runbook]
    D --> E[存入知識庫]

    F[下次同樣問題] --> G[Agent 先回答]
    G --> H{能解決?}
    H -->|是| I[不打擾 Brent]
    H -->|否| J[升級給 Brent<br/>+ 記錄新知識]

Agent 做的事很單純：

1. 觀察 Brent 每次救火時做了什麼（terminal 指令、查了哪個 log、改了哪個設定）
2. 自動生成結構化 runbook：「問題：XXX -> 原因：YYY -> 解決步驟：ZZZ」
3. 下次有人問同樣問題，Agent 先回答
4. 如果是新問題，升級給 Brent，同時記錄下來

This is 2026 年的做法：Knowledge Agent 不是要取代 Brent，而是 讓 Brent 的知識變成可複製的資產。

• 第一次遇到問題：Brent 花 20 分鐘解決，Agent 記錄
• 第二次遇到問題：Agent 直接給 runbook，5 分鐘搞定，Brent 不被打擾
• 第三次遇到問題：團隊其他人看 runbook 就能自己做

Brent 終於可以專注在真正的難題上，而不是重複回答同樣的問題。

更重要的是，這個 Knowledge Agent 還能幫你看見一件事：哪些問題一直重複出現。

如果「測試環境掛掉」這個問題每週被問五次，那代表你該建立自助式權限申請系統。

如果「部署失敗怎麼回滾」被問了十次，那代表部署流程本身有問題，該修的是流程而不是教人怎麼救火。

Agent 不只是解決當下的求救，它還能幫你看見系統性的問題。

現場推演：那個「所有查詢都在一個人腦裡」的團隊

來看一個業界常見的情況（綜合改編，數字為示意）。

某個資料分析團隊，所有 Snowflake 查詢邏輯、ETL 規則、資料定義都在一個資深分析師腦裡。他是那種「你要什麼數據我馬上寫 SQL 給你」的神人。

業務團隊愛死他了：「找他就對了，五分鐘就有結果。」

但數據主管發現一個問題：那位分析師請假一週，整個分析看板就停擺。其他人不知道某個欄位怎麼算的、join 邏輯為什麼這樣寫、為什麼要 exclude 某些條件。

更糟糕的是，每次業務來問「能不能幫我拉個數據」，那位分析師都會放下手上的工作去幫忙——因為「我自己寫比教別人快」。

結果：

• 他的行事曆被「幫忙拉數據」塞滿，真正的分析專案一直延
• 團隊其他人無法成長，因為學不到那些查詢邏輯
• Bus Factor = 1，他一離職整個分析體系就斷了

後來，團隊導入一個簡單的做法：

1. 每次那位分析師寫新查詢，都記錄一份簡單的文件：「這個查詢在算什麼、為什麼這樣寫、有哪些注意事項」
2. 建立一個共享的 SQL snippet 庫，常見查詢存成 template
3. 設立一個規則：業務來要數據，先看 snippet 庫有沒有現成的

三個月後：

• 60% 的數據請求可以由其他人處理，用現成的 template
• 那位分析師的「被打斷次數」從每週 20 次下降到 8 次
• 團隊整體的分析產能提升 35%

Brent 的價值不是「只有他能做」，而是「把他的能力複製給團隊」。

今日金句

「英雄主義撐不起系統，只會延長崩潰的時間。真正的解法是把英雄的能力變成團隊的能力。」

留給你的問題

你的團隊，現在的 Brent 是誰？

那個「什麼都找他」的人。

那個「他一請假大家就慌」的人。

那個「專案沒有他就轉不動」的人。

如果你想到了名字，那你就知道你的單點故障在哪裡。

明天，我們會看到一個更可怕的場景：那天 Brent 沒接電話。

然後你會學到，為什麼 每一次為英雄救援鼓掌，都是在為下一場災難鋪路。

Day 5 見。